Secure boot for vehicular systems

ABSTRACT

A method for a secure boot of a vehicular system is provided. The method includes performing a security self-verification on a first electronic control unit (ECU) of a vehicular system and sending a security challenge to a second electronic control unit of the vehicular system. The method includes verifying a security response from the second electronic control unit, the security response relating to the security challenge and indicating an aspect of contents of memory of the second electronic control unit. The performing the security self-verification and verifying the security response establishes a chain of trust that includes the first electronic control unit and the second electronic control unit.

This application claims benefit of priority from U.S. ProvisionalApplication No. 61/981,070 filed Apr. 17, 2014, which is herebyincorporated by reference.

BACKGROUND

Modern vehicles, such as cars, trucks, busses and other personal andcommercial vehicles, have many Electronic Control Units (ECUs) installedtherein, typically on the order of ten or more ECUs per vehicle. ECUscommunicate with each other for sending and receiving control messagesand system data over the internal Controller Area Network (CAN) bus. Inaddition, there is an OBD-II (onboard diagnostics, second generation)port connected to the CAN bus which allows a technician or other user toconnect certain diagnostics devices to the internal CAN bus in order toperform functions such as retrieving information or reprogramming aspecified ECU. Recently, researchers have discovered a number of cyberattacks which can compromise some ECUs (such as telematics ECUs) byleveraging the external interfaces to compromise an ECU, orreprogramming an ECU with a manipulated firmware through the OBD-IIport. Potentially, an attacker could gain entrance through the OBD-IIport, Bluetooth, cellular telephonic communication, a CD drive, voicecontrol, or other port or peripheral connected to the CAN bus. Once anattacker gains control of a compromised ECU, the attacker can injectillegitimate CAN messages onto the CAN bus to control the vehicle.

The embodiments arise in this context.

SUMMARY

In some embodiments, a method for a secure boot of a vehicular system isprovided. The method includes performing a security self-verification ona first electronic control unit (ECU) of a vehicular system and sendinga security challenge to a second electronic control unit of thevehicular system. The method includes verifying a security response fromthe second electronic control unit, the security response relating tothe security challenge and indicating an aspect of contents of memory ofthe second electronic control unit. The performing the securityself-verification and verifying the security response establishes achain of trust that includes the first electronic control unit and thesecond electronic control unit.

In some embodiments, a tangible, non-transitory, computer-readable mediahaving instructions thereupon which, when executed by a processor, causethe processor to perform a method. The method includes performing asecurity self-check of a first electronic control unit of a vehicularsystem, wherein the processor is included in the first electroniccontrol unit of the vehicular system. The method includes generating asecurity challenge and transmitting the security challenge to a secondelectronic control unit of the vehicular system, via a network or bus ofthe vehicular system. The method includes receiving a security responsefrom the second electronic control unit, via the network or bus, whereinthe security response is in reply to the security challenge and relatesto memory contents of the second electronic control unit. The methodincludes verifying the security response, wherein verifying the securityresponse validates at least a portion of the memory contents of thesecond electronic control unit.

In some embodiments, a vehicular system with secure boot is provided.The system includes a vehicular network or bus and a primary electroniccontrol unit, coupled to the vehicular network or bus. The primaryelectronic control unit having a processor, a security module, achallenge generator and a response checker. The security module isconfigured to perform a self-check of the primary electronic controlunit. The challenge generator is configured to generate a securitychallenge and to send the security challenge to a secondary electroniccontrol unit of the vehicular system via the vehicular network or bus.The response checker is configured to receive a security response fromthe secondary electronic control unit and configured to check thesecurity response as to validity of at least a portion of contents ofmemory of the secondary electronic control unit.

Other aspects and advantages of the embodiments will become apparentfrom the following detailed description taken in conjunction with theaccompanying drawings which illustrate, by way of example, theprinciples of the described embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The described embodiments and the advantages thereof may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings. These drawings in no waylimit any changes in form and detail that may be made to the describedembodiments by one skilled in the art without departing from the spiritand scope of the described embodiments.

FIG. 1 is a system diagram depicting a primary electronic control unitperforming a self-check, followed by challenges to and responses frommultiple secondary electronic control units, in a vehicular system inaccordance with some embodiments.

FIG. 2 is a system diagram showing internal details of the electroniccontrol units, and further details of the vehicular system of FIG. 1 inaccordance with some embodiments.

FIG. 3 is a flow diagram of a method for a secure boot of a vehicularsystem, which can be practiced on or by embodiments shown in FIGS. 1 and2 in accordance with some embodiments.

FIG. 4 is an illustration showing a computing device which may implementthe embodiments described herein.

DETAILED DESCRIPTION

The embodiments provide a vehicular system with multiple electroniccontrol units (ECUs) constructs a chain of trust for the electroniccontrol units, in order to protect the vehicular system from cyberattacks. The system first verifies one of the electronic control units,generally the most powerful device, which is equipped with securityhardware, firmware and/or software. Then, the system verifies each ofthe other electronic control units. This leverages the first verifieddevice and extends the chain of trust. Protecting the vehicular systemfrom cyber attacks by using a secure boot ensures that, upon the vehiclebeing started, each electronic control unit is verified. The vehiclesystem is booted from a clean and authenticated state, so that noimplanted malware can survive over re-boot.

Determination of which electronic control unit to verify first should bemade during system design, development or configuration. Generally, oncethe vehicular system is installed in a vehicle, the selection of whichelectronic control unit to verify first is not changed, although theelectronic control units may be updatable or upgradable under certaincircumstances. Electronic control units in a vehicle may have comparablecomputing power and resources, but generally differ in these aspects.Generally, the most powerful electronic control unit in the vehicularsystem (i.e., the one with the fastest processor and/or the processorwith the most bit width and resources) should verify first. A goodchoice for the electronic control unit to verify first, in oneembodiment, is the infotainment or telematics unit, although anotherelectronic control unit could be specified in further embodiments.

Infotainment combines information and entertainment. Telematics combinestelecommunications and various vehicular technologies, and may include aglobal positioning system (GPS) module, e.g., in navigation systems.Increasingly, telematics systems are making use of mobile data andwireless data communications. Some units combine infotainment andtelematics. An infotainment system may have, for example, a CD player, aviewscreen, a universal serial bus (USB) port, Bluetooth connectivity(for cell phone use), cellular telephonic connectivity (which mayinclude Internet connectivity), satellite connectivity (for satelliteradio and/or satellite television) and so on. Some of these externaluser interfaces or ports are vulnerable to attack.

An infotainment or telematics unit typically has the greatestcomputational resources (such as CPU or central processing unit, andmemory) among all of the electronic control units, and in some sense maybe thought of as the “brain” of the vehicle. Some vehicle manufacturers(such as Ford) use ARM (Acorn RISC Machine, a reduced instruction setcomputing architecture) processors in infotainment units. Some of theseARM processors have a feature known as Trustzone security extension,which can be leveraged as a hardware-based root of trust to verify thecomputational stack, in present embodiments. Other electronic controlunits may have more limited processors and hardware-based root of trustmay not be available on these. Generally the more powerful electroniccontrol unit is the best candidate for the first-to-verify unit inpresent embodiments of a vehicular system. The remaining electroniccontrol units are verified using the leverage of the first verifieddevice.

FIG. 1 is a system diagram depicting a primary electronic control unit102 performing a self-check, followed by challenges to and responsesfrom multiple secondary electronic control units 104A, 104B, 104N, in avehicular system. The designation of one of the electronic control unitsas the primary electronic control unit 102, and the other electroniccontrol units as secondary electronic control units 104A, 104B, . . .104N is not arbitrary. The primary electronic control unit 102 is thefirst electronic unit to verify, and self-verifies by performing aself-check. This begins the chain of trust. The chain of trust is thenextended to the secondary electronic control units 104A, 104B, . . .104N. The secondary electronic control units 104A, 104B, 104N, do notnecessarily self-verify by performing the same self-check as the primaryelectronic control unit 102, as they may lack this capability, butinstead are verified by the primary electronic control unit 102. Theprimary electronic control unit 102 sends a challenge to each of thesecondary electronic control units 104A, 104B, 104N. Each of thesecondary electronic control units 104A, 104B, 104N, sends back aresponse to the challenge. Further details of challenges and responses,and verifications, are discussed below with reference to FIG. 2. Byfollowing this sequence, the chain of trust is established for theprimary electronic control unit 102 and extended to each of thesecondary electronic control units 104A, 104B, 104N, until allelectronic control units are verified.

Some embodiments may have as few as two electronic control units (e.g.,a primary electronic control unit 102 and a secondary electronic controlunit 104A), but will typically have more than two electronic controlunits. If an attacker has installed malware in any of the electroniccontrol units 102, 104A, 104B, . . . 104N, the malware is detectedduring the above sequence. The system can then indicate that anelectronic control unit 102, 104A, 104B, . . . 104N is compromised,e.g., by posting a message on a display of an infotainment or telematicsunit, illuminating a lamp on a dashboard display, sending a troublecode, and/or branching to a failsafe routine. A failsafe routine couldisolate the compromised electronic control unit, or use a subset ofoperations or a differing set of operations (such as “limp home mode”).

FIG. 2 is a system diagram showing internal details of the electroniccontrol units 102, 104A, . . . 104N, and further details of thevehicular system of FIG. 1. A Controller Area Network 202 (also known asa CAN or CAN bus) couples the electronic control units 102, 104A, . . .104N, supporting communication among the electronic control units. Insome embodiments, an onboard diagnostics port 204, for example a portconforming to the second-generation OBD-II standard, is coupled to thecontroller area network 202. The onboard diagnostics port 204 isemployed, e.g., by a technician at an automobile repair shop ordealership for diagnostics of the vehicular system, and may be employedto update or upgrade components (e.g., to “flash” updated programminginto an electronic control unit). Some embodiments are accompanied byexternal verification of the primary electronic control unit 102 and/orthe secondary electronic control units 104A, . . . 104N. Thisverification could be performed via the onboard diagnostics port 204, orother access point, using various methods. An attacker may also employthe onboard diagnostics port 204, an access point through the primaryelectronic control unit 102, one or more of the secondary electroniccontrol units 104A, . . . 104N, or other access point in order toprogram malware into an electronic control unit.

In the embodiment shown in FIG. 2, the primary electronic control unit102 has a CPU 206, an infotainment or telematics module 210, a securitymodule 212, a challenge generator 214, and the response checker 216. Theprimary electronic control unit 102 may have other components as well,for example components related to specific functions performed by, andfeatures of, the electronic control unit 102. Such components couldinclude modules for a display screen, a touchscreen, various controlinputs, a global positioning system (GPS) unit, navigation systems,audio systems, and so on. Some of these may be part of the infotainmentor telematics module 210. The CPU 206 may participate in the processingfor various modules, or one or more modules may have a CPU dedicated tothat module, and one or more modules may be reprogrammable (e.g., withflash memory, a replaceable read-only memory or ROM, or an erasableprogrammable read-only memory or EPROM).

The security module 212 forms the foundation for a secure boot system.Some or all of the security module 212 resides in hardware, maskprogrammed read-only memory (ROM), one-time programmable (OTP) memory,or one-time programmable firmware, in some embodiments. The primaryelectronic control unit 102 self-verifies, to establish the chain oftrust. In this embodiment, the security module 212 performs a self-checkof itself and of a boot loader 224. The boot loader 224 is responsiblefor booting up the primary electronic control unit 102, includingbooting up the CPU 206. Duties of the boot loader 224 could includeinitializing I/O, initializing various parameters, initializing datamemory, configuring various peripheral devices and/or other tasksrelated to the initial state of the primary electronic control unit 102.The self-check should be performed in response to power up and/or systemreset. As an example of the self-check, some embodiments include apublic key and a verification script stored in one time programmablememory, one-time programmable firmware or hardware, or on a system onchip (On-SoC). The use of one time programmable electronics allows thepublic key and the verification script to be programmed in initially,but an attacker cannot reprogram these, since one time programmablecircuitry is not erasable and reprogrammable. The security module 212executes the verification script, for example on a dedicated securityco-processor, or a processor which is part of the security module 212,or on the CPU 206, as a further example. The verification scriptverifies the security module 212, the boot loader 224, and selectedportions or the entirety of the remainder of the primary electroniccontrol unit 102. In some versions, a public key (as discussed above) isapplied during the verification. For example, the security module 212could execute the verification script, which performs a keyed hashfunction calculation on portions or all of a program memory of theprimary electronic control unit 102, producing a hash function result.This hash function result is then compared to a previously calculated orpredetermined and stored value. The stored value may be stored in thesecurity module 212 or elsewhere in the primary electronic controllerunit 102 in some embodiments. If the two values are equal, theself-verification is complete and the primary electronic control unit102 is self-verified. Some embodiments of the security module 212 haveand apply the Trustzone security extension as described above. Furtherembodiments employ various further mechanisms and methods forself-verification as readily devised in accordance with the teachingsherein.

The secure boot system and process adds cryptographic checks to eachstage of a secure world boot process, which aims to assert the integrityof all of the secure world software images that are executed, preventingany unauthorized or maliciously modified software from running. Once theprimary electronic control unit 102 is self-verified, via the securitymodule 212, the secure boot and process extends the chain of trust toeach of the secondary electronic control units 104A, . . . 104N. It doesso by having the challenge generator 214 issue security challenges tothe secondary electronic control units 104A, . . . 104N, and having theresponse checker 216 verify security responses from the secondaryelectronic control units 104A, . . . 104N.

The security response indicates an aspect of contents of memory of thesecondary electronic control unit 104A, . . . 104N, which is verified orvalidated by the response checker 216 of the primary electronic controlunit 102. Information stored in the primary electronic control unit 102,for use in verifying the security responses, is individualized andpertains to the contents of the memory of each of the secondaryelectronic control units 104A, . . . 104N. In some embodiments, thisinformation is part of the response checker 216, and some or all of theresponse checker resides in reprogrammable memory or reprogrammablefirmware. With such embodiments, the response checker 216, and moreparticularly the information used by the response checker 216 to verifythe security responses, is updatable (reprogrammable) in the event of anupdate or an upgrade to one or more of the secondary electronic controlunits 104A, . . . 104N.

In the embodiment shown in FIG. 2, the secondary electronic control unit104A has a CPU 208, a challenge response generator 218, a functionalmodule 220, and unused memory 222. The CPU 208 could be similar to theCPU 206 of the primary electronic control unit 102, or could differ fromthat. Generally, the CPU 208 of the secondary electronic control unit104A is less powerful than the CPU 206 of the primary electronic controlunit 102, but this is not a requirement. The functional module 220 isvehicle-specific, and could include functions for heating, ventilationand air-conditioning (HVAC or climate control), engine control,transmission control, antilock brakes, lighting, electric windows,electric doors, seat adjustment, or mirror adjustment, and so on. Whilethe secondary electronic control unit 104A is shown as having unusedmemory 222, it should be appreciated that the challenge responsegenerator 218 and the functional module 220 may each have memory whichis used, e.g., for program storage and/or data storage. It is alsopossible that a secondary electronic control unit 104 could use all ofthe memory and not have unused memory 222. The challenge responsegenerator 218, which could be a software module, firmware module orhardware module, generates a response according to the challengereceived from the primary electronic control unit 102.

With ongoing reference to FIGS. 1 and 2, multiple scenarios andmechanisms are applicable to various embodiments of the vehicularsystem. To verify the booting state of the secondary electronic controlunits 104A, . . . 104N, the system employs software-based remoteattestation and uses an already-verified device, i.e., the primaryelectronic control unit 102, as the trusted tester. In particular, thetrusted tester generates a challenge, which in some embodiments is arandomized challenge, and sends the challenge to the to-be-testedelectronic control unit 104A, . . . 104N, over the controller areanetwork 202. The secondary electronic control unit 104A, . . . 104Ncomputes or otherwise generates a response to the received challenge,based on the computational state of the secondary electronic controlunit 104A, . . . 104N. One mechanism includes checking if theto-be-verified program (e.g. in the secondary electronic control unit104A) has the correct memory layout, including both location andcontent. Examples of this type of remote attestation designs includedesigns that provide the guarantee of “verifiable code execution” on acomputing system to an external verifier. That is, the verifier obtainsan assurance that the execution of an arbitrary piece of code on acomputing system cannot be tampered with by any malware that may bepresent on the computing system. In some embodiments, the primaryelectronic control unit 102 verifies some or all of the memory of thesecondary electronic unit 104A as to location and content.

Another mechanism for checking is to stuff the unused memory 222 of asecondary electronic control unit 104A with previously determined data(e.g., a repeated bit sequence, number or character). This leaves noextra space in which malware could reside. The challenge could request acalculation be performed on data from the supposedly unused memory 222,with results of the calculation sent back as the response. A calculationresult value differing from an expected result could indicatecorruption, e.g., by malware. Another mechanism for checking is toexpect that the response is sent back before a time threshold. Maliciouscode in a compromised electronic control unit 104A might cause theresponse to have a different time delay, e.g., might slow the responsetime of the electronic control unit 104A. This could be detected byhaving the primary electronic control unit 102 start a timer 226, ornote a time value on an already running timer 226, when the challenge issent from the primary electronic control unit 102 to the secondaryelectronic control unit 104A. Upon receipt of the response from thesecondary electronic control unit 104A, the primary electronic controlunit 102 could stop the timer 226 or note the time value, and deduce aresponse time for the secondary electronic control unit 104A inresponding to the challenge. This response time could then be comparedto a time threshold. The time threshold could be established bysimulating, testing, or characterizing the system. If the response timeis longer than the time threshold, or in some embodiments shorter thanthe time threshold, or outside of a time threshold range, this couldindicate a compromised secondary electronic control unit 104A. Someembodiments have a timeout feature so that the system does not hang. Yetanother mechanism for checking is to have the secondary electroniccontrol unit 104A read a portion of memory and perform a calculation oran operation thereupon. The calculation could be performed upon programdata starting at a fixed address, or a randomized address specified inthe challenge, or upon the entirety of the program memory, in variousembodiments.

The challenge could indicate, or be interpreted by the secondaryelectronic control unit 104A as, a request for a result of a cyclicredundancy check (CRC) calculation, a hash calculation, an exclusive or(XOR) calculation, a keyed hash calculation, or a statisticalcalculation or sampling (e.g., a spot check), over a portion or all ofthe program memory of the secondary electronic control unit 104A in someembodiments. The secondary electronic control unit 104A would thenperform the calculation or sampling and send back the result of thiscalculation or sampling. The primary electronic control unit 102 couldcompare this result to a previously stored (i.e., predetermined) valuein memory in the primary electronic control unit 102.

The challenge could indicate, or be interpreted by the secondaryelectronic control unit 104A as, a request for a result of an imagecompression of, or a copy of, some or all of the program memory of thesecondary electronic control unit 104A in some embodiments. Thesecondary electronic control unit 104A would then send back the resultof this image compression or copy. The primary electronic control unit102 could compare the result to a previously stored compressed image oruncompressed copy of the program memory of the secondary electroniccontrol unit 104A, which is stored in memory in the primary electroniccontrol unit 102.

The challenge could include one or more randomized addresses, along withan explicit or interpretable request as above. The secondary electroniccontrol unit 104A would then access its memory at the randomized addressor addresses, perform a calculation, a sampling, an image compression,or a copy relative to the randomized address or addresses, and returnresults in the response. The primary electronic control unit 102 couldthen compare these results to an appropriate and correspondingpreviously stored data set in the memory in the primary electroniccontrol unit 102.

In various embodiments, according to the above scenarios, the responsechecker 216 on the primary electronic control unit 102 could include orbe coupled to various types of information to be applied when verifyingthe response from a secondary electronic control unit 104A. Thisinformation could include a copy or a compressed image of some or all ofthe memory of the secondary electronic control unit 104A (and of otherelectronic control units 104N), statistical information, cyclicredundancy check values, exclusive or calculation values, hashcalculation values, keyed hash calculation values or other calculationresults. These calculation results could be performed prior to or duringinitial system installation, or system upgrade, and stored in memory onthe primary electronic control unit 102. Alternatively, thesecalculations could be performed on a copy of program memory of each ofthe secondary electronic control units 104A, . . . 104N, with thesecopies stored on the electronic control unit 102. Calculations could beperformed on compressed images stored on the electronic control unit102, with or without decompression as appropriate to the type ofcalculation.

Goals for verifying the primary electronic control unit 104 or thesecondary electronic control units 104A, . . . 104N could includeverifying that firmware is not modified, verifying the program code isunmodified, and/or verifying that a software stack of multiple layers ofsoftware is unmodified. The types and contents of the challenges andresponses, and also of the self-check, can be tailored to accomplishsome or all of these goals. For example, security checking of thesoftware stack could proceed up one layer at a time. A more detailedcheck could provide byte for byte or word for word comparisons, while aless detailed check could involve a calculation over a section of memoryor the entire contents of memory. Multiple types of checks can becombined in some embodiments.

In some embodiments, an upgrade or update is allowed on one or more ofthe secondary electronic control units 104A, . . . 104N. This couldinclude replacing or reprogramming an electronic control unit 104A, . .. 104N. The update could occur via the onboard diagnostics port 204, or,in some embodiments, the update could be an over-the-air update via awireless port, e.g., Bluetooth or satellite radio. In embodimentsallowing upgrade or update, the information stored on the electroniccontrol unit 102 should also be updated, so that verification ofchallenge responses can be accurately performed on upgraded or updatedelectronic control units 104A, . . . 104N. Some embodiments perform thisupdating automatically, e.g., by the primary electronic control unit 102monitoring the updating or upgrading of a secondary electronic controlunit 104A and copying, compressing, or performing calculations based on,the updated program code of the secondary electronic control unit 104A.Other embodiments have this updating performed by an external agent,e.g., an external device communicating through the onboard diagnosticsport 204 or other access point. It should be appreciated that suchexternal updating should be accompanied by appropriate securitymeasures, e.g., encryption, authentication, etc., in order to decreaserisk of an attacker defeating the above-described secure bootmechanisms. It should be further appreciated that the techniques andmechanisms disclosed herein can further be applied to diagnostics forsome types of failure, such as dropped bits, corrupted memory,accidental erasure, or power loss to a memory component, to name a few.

FIG. 3 is a flow diagram of a method for a secure boot of a vehicularsystem, which can be practiced on or by embodiments shown in FIGS. 1 and2. More specifically, the method can be practiced by the processors ofthe electronic control units in embodiments of the vehicular systemdescribed above. Electronic control units in the vehicular system arecategorized as first or second electronic control units. The firstelectronic control unit has the capability to self-verify. Secondelectronic control units are not required to have self-verify capabilityequal to that of the first electronic control unit, but should be ableto respond to a security challenge by issuing a security response.Communication among electronic control units occurs along a vehicularnetwork or bus.

The first electronic control unit self-verifies, in an action 302 ofFIG. 3. For example, a processor of the first electronic control unit,or a dedicated security processor or co-processor, could execute averification script and authenticate the boot loader. This mechanismcould apply a key, in some embodiments, for example in a keyed hashfunction applied to the contents of a memory that holds the boot loader.In a decision action 304, it is determined whether the self-verificationpasses. If the self-verification does not pass, flow branches to theaction 306, to indicate failure. Failure could be indicated byactivating a display such as an indicator lamp or an on-screen message,e.g., in a telematics or infotainment unit, or some other audible orvisual indicator. Failure could be indicated by branching to adiagnostic process or a failsafe process. If the self-verification doespass, flow branches to the action 308.

Still referring to FIG. 3, the first electronic control unit generates asecurity challenge, in action 308. In some embodiments, this israndomized. The security challenge could request that the secondelectronic control unit fetch data from some randomized address, or sendback a result of a calculation performed on some or all of the memory ofthe second electronic control unit, for example. The first electroniccontrol unit sends the security challenge to the second electroniccontrol unit, in an action 310. For example, in the vehicular system,the security challenge could be sent via the controller area network. Insome embodiments, a timer is started or a time value noted, in order tomeasure the response time of the second electronic control unit withregard to responding to the security challenge.

The second electronic control unit generates a security response, inaction 312. This depends on, and is in response to, the securitychallenge. For example, if the security challenge specifies an address,the second electronic control unit could interpret this as a request fordata from that address in the memory of the second electronic controlunit, or a calculation on data starting at that address in the memory.Alternatively, the security challenge could be a code word or phrase,and the second electronic control unit could interpret this via a lookuptable, etc. The second electronic control unit could perform acalculation on all of the data in the memory, or a subset of the data,or on an address range as indicated by the security challenge. Thesecond electronic control unit sends the security response to the firstelectronic control unit, in action 314. For example, the securityresponse could be sent via the controller area network. Upon receivingthe security response, in some embodiments, the first electronic controlunit stops the timer or otherwise acquires a measurement of the responsetime of the second electronic unit.

The first electronic control unit verifies the security response, inaction 316 of FIG. 3. This could include stopping or checking a timerupon receipt of the security response, and comparing the response timeto a time threshold, with a too-long response time indicating acompromised system. Verifying the security response could includecomparing data in the security response to previously stored data in thefirst electronic control unit, such as data generated duringdevelopment, initial installation, or upgrade of the system. If thesecurity response fails to verify, this could indicate a compromisedsystem. In a decision action 318, it is determined whether theverification by the first electronic control unit of the securityresponse from the second electronic control unit passes. If theverification of the security response does not pass, flow branches tothe action 320, to indicate failure. Failure could be indicated throughany of the mechanisms indicated above. In some embodiments, failurecould be indicated by branching to a diagnostic process or a failsafeprocess. If the self-verification does pass, flow branches to thedecision action 322.

In the decision action 322, it is determined whether all secondelectronic control units are verified. If not all second electroniccontrol units are verified, flow branches to the action 324, to point tothe next second electronic control unit. Once the system is ready, i.e.,pointing to the next second electronic control unit, flow returns backto the action 308, so that the first electronic control unit cangenerate a security challenge for the next second electronic controlunit and perform the verification as discussed above. If all of thesecond electronic control units are verified, flow proceeds to theaction 326. In the action 326, normal system operation commences orotherwise takes place, as the system has completed or is soon tocomplete a secure boot. At such time, the first electronic control unithas self-verified, and the first electronic control unit has verifiedall of the security responses, i.e., has verified all of the secondelectronic control units. With the chain of trust established andincluding the first electronic control unit and all second electroniccontrol units, the system can perform normal operation in confidencethat the electronic control units have not been compromised.

It should be appreciated that the methods described herein may beperformed with a digital processing system, such as a conventional,general-purpose computer system. Special purpose computers, which aredesigned or programmed to perform only one function may be used in thealternative. FIG. 4 is an illustration showing an exemplary computingdevice which may implement the embodiments described herein. Thecomputing device of FIG. 4 may be used to perform embodiments of thefunctionality for self-verification and/or verification of otherelectronic control units in accordance with some embodiments. Thecomputing device includes a central processing unit (CPU) 401, which iscoupled through a bus 405 to a memory 403, and mass storage device 407.Mass storage device 407 represents a persistent data storage device suchas a floppy disc drive or a fixed disc drive, which may be local orremote in some embodiments. The mass storage device 407 could implementa backup storage, in some embodiments. Memory 403 may include read onlymemory, random access memory, etc. Applications resident on thecomputing device may be stored on or accessed via a computer readablemedium such as memory 403 or mass storage device 407 in someembodiments. Applications may also be in the form of modulatedelectronic signals modulated accessed via a network modem or othernetwork interface of the computing device. It should be appreciated thatCPU 401 may be embodied in a general-purpose processor, a specialpurpose processor, or a specially programmed logic device in someembodiments.

Display 411 is in communication with CPU 401, memory 403, and massstorage device 407, through bus 405. Display 411 is configured todisplay any visualization tools or reports associated with the systemdescribed herein. Input/output device 409 is coupled to bus 405 in orderto communicate information in command selections to CPU 401. It shouldbe appreciated that data to and from external devices may becommunicated through the input/output device 409. CPU 401 can be definedto execute the functionality described herein to enable thefunctionality described with reference to FIGS. 1-3. The code embodyingthis functionality may be stored within memory 403 or mass storagedevice 407 for execution by a processor such as CPU 401 in someembodiments. The operating system on the computing device may be MSDOS™, MS-WINDOWS™, OS/2™, UNIX™, LINUX™, or other known operatingsystems. It should be appreciated that the embodiments described hereinmay be integrated with virtualized computing system also.

Detailed illustrative embodiments are disclosed herein. However,specific functional details disclosed herein are merely representativefor purposes of describing embodiments. Embodiments may, however, beembodied in many alternate forms and should not be construed as limitedto only the embodiments set forth herein. While the embodiments areapplied to a vehicle system this is not meant to be limiting. Inaddition, while the vehicle system may be a land, sea, or air basedsystem, the embodiments may be extended to non-vehicle systems also.

It should be understood that although the terms first, second, etc. maybe used herein to describe various steps or calculations, these steps orcalculations should not be limited by these terms. These terms are onlyused to distinguish one step or calculation from another. For example, afirst calculation could be termed a second calculation, and, similarly,a second step could be termed a first step, without departing from thescope of this disclosure. As used herein, the term “and/or” and the “/”symbol includes any and all combinations of one or more of theassociated listed items.

As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, and/or “including”, when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. Therefore, the terminology usedherein is for the purpose of describing particular embodiments only andis not intended to be limiting.

It should also be noted that in some alternative implementations, thefunctions/acts noted may occur out of the order noted in the figures.For example, two figures shown in succession may in fact be executedsubstantially concurrently or may sometimes be executed in the reverseorder, depending upon the functionality/acts involved.

With the above embodiments in mind, it should be understood that theembodiments might employ various computer-implemented operationsinvolving data stored in computer systems. These operations are thoserequiring physical manipulation of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared, and otherwise manipulated. Further, the manipulationsperformed are often referred to in terms, such as producing,identifying, determining, or comparing. Any of the operations describedherein that form part of the embodiments are useful machine operations.The embodiments also relate to a device or an apparatus for performingthese operations. The apparatus can be specially constructed for therequired purpose, or the apparatus can be a general-purpose computerselectively activated or configured by a computer program stored in thecomputer. In particular, various general-purpose machines can be usedwith computer programs written in accordance with the teachings herein,or it may be more convenient to construct a more specialized apparatusto perform the required operations.

A module, an application, a layer, an agent or other method-operableentity could be implemented as hardware, firmware, or a processorexecuting software, or combinations thereof. It should be appreciatedthat, where a software-based embodiment is disclosed herein, thesoftware can be embodied in a physical machine such as a controller. Forexample, a controller could include a first module and a second module.A controller could be configured to perform various actions, e.g., of amethod, an application, a layer or an agent.

The embodiments can also be embodied as computer readable code on atangible non-transitory computer readable medium. The computer readablemedium is any data storage device that can store data, which can bethereafter read by a computer system. Examples of the computer readablemedium include hard drives, network attached storage (NAS), read-onlymemory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes,and other optical and non-optical data storage devices. The computerreadable medium can also be distributed over a network coupled computersystem so that the computer readable code is stored and executed in adistributed fashion. Embodiments described herein may be practiced withvarious computer system configurations including hand-held devices,tablets, microprocessor systems, microprocessor-based or programmableconsumer electronics, minicomputers, mainframe computers and the like.The embodiments can also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a wire-based or wireless network.

Although the method operations were described in a specific order, itshould be understood that other operations may be performed in betweendescribed operations, described operations may be adjusted so that theyoccur at slightly different times or the described operations may bedistributed in a system which allows the occurrence of the processingoperations at various intervals associated with the processing.

In various embodiments, one or more portions of the methods andmechanisms described herein may form part of a cloud-computingenvironment. In such embodiments, resources may be provided over theInternet as services according to one or more various models. Suchmodels may include Infrastructure as a Service (IaaS), Platform as aService (PaaS), and Software as a Service (SaaS). In IaaS, computerinfrastructure is delivered as a service. In such a case, the computingequipment is generally owned and operated by the service provider. Inthe PaaS model, software tools and underlying equipment used bydevelopers to develop software solutions may be provided as a serviceand hosted by the service provider. SaaS typically includes a serviceprovider licensing software as a service on demand. The service providermay host the software, or may deploy the software to a customer for agiven period of time. Numerous combinations of the above models arepossible and are contemplated.

Various units, circuits, or other components may be described or claimedas “configured to” perform a task or tasks. In such contexts, the phrase“configured to” is used to connote structure by indicating that theunits/circuits/components include structure (e.g., circuitry) thatperforms the task or tasks during operation. As such, theunit/circuit/component can be said to be configured to perform the taskeven when the specified unit/circuit/component is not currentlyoperational (e.g., is not on). The units/circuits/components used withthe “configured to” language include hardware—for example, circuits,memory storing program instructions executable to implement theoperation, etc. Reciting that a unit/circuit/component is “configuredto” perform one or more tasks is expressly intended not to invoke 35U.S.C. 112, sixth paragraph, for that unit/circuit/component.Additionally, “configured to” can include generic structure (e.g.,generic circuitry) that is manipulated by software and/or firmware(e.g., an FPGA or a general-purpose processor executing software) tooperate in manner that is capable of performing the task(s) at issue.“Configured to” may also include adapting a manufacturing process (e.g.,a semiconductor fabrication facility) to fabricate devices (e.g.,integrated circuits) that are adapted to implement or perform one ormore tasks.

The foregoing description, for the purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the embodiments and its practical applications, to therebyenable others skilled in the art to best utilize the embodiments andvarious modifications as may be suited to the particular usecontemplated. Accordingly, the present embodiments are to be consideredas illustrative and not restrictive, and the invention is not to belimited to the details given herein, but may be modified within thescope and equivalents of the appended claims.

What is claimed is:
 1. A method for a secure boot of a system,comprising: a primary electronic control unit (ECU) of the systemperforming, in response to a boot of the system, a securityself-verification on the primary ECU to verify the primary ECU by asecurity module of the primary ECU locally executing a verificationscript permanently stored locally in read-only memory (ROM) of theprimary ECU such that the verification script cannot be remotelyupdated; the primary ECU sending, after the performing of the securityself-verification, a security challenge to a secondary ECU of thesystem; and the primary ECU verifying a security response received fromthe secondary ECU in response to the security challenge, the securityresponse relating to the security challenge and indicating an aspect ofcontents of memory of the secondary ECU, wherein the performing of thesecurity self-verification and the verifying of the security responseestablishes a chain of trust between the primary ECU and the secondaryECU.
 2. The method of claim 1, wherein the performing of the securityself-verification includes applying a public key and the verificationscript to authenticate a boot loader of the primary ECU.
 3. The methodof claim 1, further comprising: the primary ECU randomizing the securitychallenge prior to the sending.
 4. The method of claim 1, wherein theverifying of the security response includes comparing a time thresholdto a response time of the secondary ECU in replying with the securityresponse.
 5. The method of claim 1, wherein the verifying of thesecurity response includes one of: a spot check, a cyclic redundancycheck (CRC), a hash calculation, an exclusive or (XOR) calculation, datacompression, or a copy, of at least a portion of the memory of thesecondary ECU.
 6. The method of claim 1, further comprising: the primaryECU updating information to be applied in verifying the securityresponse, responsive to an update or an upgrade to the secondary ECU. 7.A tangible, non-transitory, computer-readable media having instructionsthereupon which, when executed by a processor, cause the processor toperform a method comprising: a primary electronic control unit (ECU) ofa vehicular system performing, in response to a boot of the vehicularsystem, a security self-check on the primary ECU to verify the primaryECU by a security module of the primary ECU locally executing averification script permanently stored locally in read-only memory (ROM)of the primary ECU such that the verification script cannot be remotelyupdated; the primary ECU generating a security challenge; the primaryECU transmitting, after the performing of the security self-check, thesecurity challenge to a secondary ECU of the vehicular system through anetwork or bus of the vehicular system; the primary ECU receiving asecurity response from the secondary ECU in reply to the securitychallenge, the security response relating to contents of memory of thesecondary ECU; and the primary ECU verifying the security response tovalidate at least a portion of the content of the memory of thesecondary ECU and to establish a chain of trust between the primary ECUand the secondary ECU.
 8. The computer-readable media of claim 7,wherein: the security challenge includes a randomized address; and thesecurity response relates to data at the randomized address in thememory of the secondary ECU.
 9. The computer-readable media of claim 7,wherein the performing of the security self-check includes verifying aboot loader of the primary ECU, using a public key and the verificationscript, with the public key and the verification script stored on theprimary ECU in the ROM, which comprises one or more of: one timeprogrammable (OTP) memory and one time programmable firmware.
 10. Thecomputer-readable media of claim 7, wherein the verifying of thesecurity response includes: the primary ECU timing a response time fromwhen the security challenge is transmitted until the security responseis received; and the primary ECU comparing the response time to a timethreshold.
 11. The computer-readable media of claim 7, wherein: unusedmemory of the secondary ECU has memory stuffed with predetermined data;and the verifying of the security response includes verifying that theunused memory of the secondary ECU has the memory stuffed with thepredetermined data.
 12. The computer-readable media of claim 7, wherein:the verifying of the security response includes comparing contents ofthe security response to a predetermined result stored on the primaryECU; and the predetermined result includes a result of a previouslyperformed one of: a spot check, a cyclic redundancy check (CRC), anexclusive or (XOR) calculation, compressed data, or a copy, of at leasta portion of the contents of the memory of the secondary ECU.
 13. Avehicular system with secure boot, comprising: a vehicular network orbus; a secondary electronic control unit (ECU) coupled to the vehicularnetwork or bus; a primary ECU, coupled to the vehicular network or bus,and comprising a processor, memory, read-only memory (ROM), a securitymodule, a challenge generator and a response checker; the securitymodule configured to perform, in response to a boot of the vehicularsystem, a self-check of the primary ECU by the security module locallyexecuting a verification script permanently stored locally in the ROM ofthe primary ECU such that the verification script cannot be remotelyupdated; the challenge generator configured to generate a securitychallenge and to send, after the performing of the self-check, thesecurity challenge to the secondary ECU via the vehicular network orbus; and the response checker configured to receive a security responsefrom the secondary ECU in reply to the security challenge and configuredto check the security response to validate at least a portion ofcontents of memory of the secondary ECU and to establish a chain oftrust between the primary ECU and the secondary ECU.
 14. The vehicularsystem of claim 13, wherein: the secondary ECU is configured to receivethe security challenge and to generate the security response; and thesecurity response includes information regarding the at least theportion of the contents of the memory of the secondary ECU.
 15. Thevehicular system of claim 13, wherein: the vehicular system furthercomprises a diagnostics port coupled to the vehicular network or bus;the challenge generator is configured to send security challenges to aplurality of secondary ECUs; and the response checker is configured toreceive and check security responses from the plurality of secondaryECUs, wherein the response checker includes individualized informationregarding the at least the portion of the contents of the memory of eachof the plurality of secondary ECUs to extend the chain of trust to theplurality of secondary ECUs.
 16. The vehicular system of claim 13,wherein the response checker comprises or is coupled to one of: a copyof the at least the portion of the contents of the memory of thesecondary ECU; a compressed image of the at least the portion of thecontents of the memory of the secondary ECU; statistical informationregarding the at least the portion of the contents of the memory of thesecondary ECU; a result of a cyclic redundancy check (CRC) of the atleast the portion of the contents of the memory of the secondary ECU; ora result of an exclusive or (XOR) calculation performed on the at leastthe portion of the contents of the memory of the secondary ECU.
 17. Thevehicular system of claim 13, wherein: the response checker isconfigured to apply, in checking the security response, storedinformation regarding the at least the portion of the contents of thememory of the secondary ECU, wherein the stored information is in theprimary ECU; and the primary ECU is configured to update the storedinformation, responsive to an update or an upgrade to the secondary ECU.18. The vehicular system of claim 13, wherein: at least a portion of thesecurity module resides in the ROM, which comprises one or more of maskprogrammed read-only memory (ROM), one time programmable (OTP) memory,and one time programmable firmware; and the response checker resides atleast partially in one of: reprogrammable memory, or reprogrammablefirmware.
 19. The vehicular system of claim 13, wherein: the primary ECUfurther comprises a timer configured to measure a response time betweenthe primary ECU sending the security challenge and the primary ECUreceiving the security response; and the response checker checking thesecurity response comprises determining whether the response time iswithin a time threshold.